В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

Чтобы добавить такой аларм, нужно знать его уникальный идентификатор (ID), ассоциированный с конкретным типом события. Эти события и их ID можно посмотреть в следующем файле на хосте ESXi:

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

Если же такой аларм срабатывает, то он записывается в следующий лог-файл:

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:

Компания VMware продолжает обновлять свой веб-клиент для управления виртуальной инфраструктурой на базе технологии HTML 5 и, в принципе, к предстоящему VMworld 2017 должна уже выпустить его релизную версию. Напомним, что о прошлой версии клиента vSphere Client 3.15 мы писали вот тут.

В обновлении VMware vSphere Client 3.16 появилось немало новых возможностей и улучшений. Давайте посмотрим на них:

• Создание новой политики хранения (VM Storage Policy). Пока эта функция имеет ограничения:
  • Создание политики vSAN Policy (без тэгов)
  • Создание политики с тэгами и основными правилами
• Улучшения распределенного коммутатора Distributed Switch
  • Управление физическими сетевыми адаптерами на уровне хоста ESXi
  • Поддержка LACP - просмотр групп link aggregation на распределенном коммутаторе
  • Поддержка SR-IOV - включение/выключение этой технологии на сетевых адаптерах, которые ее поддерживают
• Компонент Content Library (импорт в библиотеку пока не работает)
  • Тэги, заметки и портлет подписки и публикации
  • Изменение настроек библиотек контента
  • Удаление библиотек
  • Функция синхронизации
• Прочие улучшения
  • Выбор стека TCP/IP при создании нового сетевого адаптера VMkernel
  • Исправления ошибок

Скачать VMware vSphere Client 3.16 можно по этой ссылке. Инструкция по его развертыванию доступна тут.

Спустя 8 лет, опять поднимем тему использования кластеров VMware HA/DRS, в которых, по каким-либо причинам, оказались разные версии хост-серверов VMware ESXi. Такой режим работы кластеров допускается со стороны VMware, но при определенных условиях.

Первая и самая важная вещь - совместимость виртуального аппаратного обеспечения виртуальных машин (Virtual Hardware Version), которое увеличивает свою версию с каждым мажорным релизом ESXi. Правило тут простое - более новые версии ESXi могут запускать и исполнять виртуальные машины более старых версий, а вот старые хосты ESXi более новое для себя "виртуальное железо" не запустят.

Данный момент проясняет табличка из KB 2007240:

Обратите внимание, что, например, ВМ с версией HW 11 вы не запустите на ESXi 5.5. Поэтому выход такой - не обновлять старое виртуальное аппаратное обеспечение виртуальных машин, даже если они переехали за счет vMotion на хосты с более новой версией HW.

Второй момент - VMware Tools. Тут уже проще - старую версию тулзов можно эксплуатировать на новых хостах, как и новую на старых - обратная совместимость тоже есть. Убедиться в этом можно с помощью онлайн-утилиты VMware Product Interoperability Matrices, где в поле "Select a Solution" надо выбрать VMware Tools, а в поле "Add Platform/Solution" - платформу VMware vSphere Hypervisor (ESXi):

Но обратная совместимость тоже не бесконечная - VMware Tools версии 10.1.5, как мы видим, не получится использовать на VMware vSphere 5.1 Update 3.

Кстати, чтобы обновить VMware Tools, можно переместить ВМ с помощью vMotion на хост ESXi с более высокой версией и выбрать пункт "Install/Upgrade VMware Tools" в vSphere Web Client.

Второй способ обновления VMware Tools - это просто скачать их по ссылке с официального репозитория для вашей гостевой ОС:

https://packages.vmware.com/tools/esx/index.html

Ну и третий, заключительный, но самый важный момент при использовании смешанных кластеров (VMware их называет mixed clusters) - это возможности VMware HA, DRS, FT и прочих функций, которые предоставляет соответствующая версия ПО от VMware.

Например, в версии vSphere 6.5 появилось много нового с точки зрения технологии HA (к примеру, механизм Admission Control стал рассчитывать параметры для несбалансированных кластеров автоматически).

Поэтому самый простой и эффективный выход - это смешанные кластеры не создавать, а создать два разных кластера - для старых и для новых хост-серверов. Да, это может вам стоить в каком-то случае на один хост больше, но это того стоит.

Недавно мы писали о том, что компания VMware выпустила обновленную версию продукта VMware vRealize Operations Manager 6.6, предназначенного для комплексного мониторинга и управления виртуальной инфраструктурой VMware vSphere. Для этого решения существует специальный пакет vRealize Operation Service Discovery Management Pack, который раньше был известен как VMware vRealize Infrastructure Navigator.

Устанавливается он как Solution (расширение) в консоли vRealize Operations Manager:

Service Discovery Management Pack производит сбор информации о зависимостях между различными компонентами виртуальной инфраструктуры, как на уровне ее объектов, так и на уровне сервисов в рамках одной или нескольких виртуальных машин.

Делается это за счет агрегации полученных данных о сервисах в виртуальных машинах и анализа сетевой коммуникации между ними. Далее на основе полученных взаимосвязей можно динамически построить приложение как совокупность сервисов в разных ВМ.

Service Discovery Management Pack позволяет ответить на следующие вопросы:

• Какие типы сервисов работают в виртуальной инфраструктуре (например, MySQL, Apache Tomcat и т.п.)
• Какая виртуальная машина является составным компонентом приложения/сервиса
• Каково будет последствие выключения или перемещения ВМ для приложения
• Каковы будут последствия инцидента и путь экскалации проблемы по иерархии сервисов
• Какие ВМ нужно переместить, чтобы переместить приложение целиком
• Какие приложения будут затронуты в случае планового простоя или недоступности компонента виртуальной инфраструктуры
• Как пользователи осведомлены о наличии в их инфраструктуре конкретного сервиса и приложения
• Какие ВМ являются частью плана аварийного восстановления
• Есть ли ВМ, которые нуждаются в защите с точки зрения восстановления на уровне площадок

Вот так выглядит окно информации о конкретной ВМ с точки зрения сервисов, которые в ней работают (обратите внимание, что в правом нижнем углу показана топология взаимосвязи для данной ВМ):

А вот так выглядят отношения сервисов, которые работают в разных ВМ, на уровне приложения, которое они составляют:

Скачать VMware vRealize Operations Service Discovery Management Pack можно по этой ссылке. Ну а вот еще несколько полезных ресурсов о продукте:

• vRealize Service Discovery Management Pack 1.0 - Release Notes
• vRealize Operations Service Discovery Management Pack 1.0.1- Release Notes
• vRealize Service Discovery Management Pack 1.0 - User guide

На днях компания VMware выпустила чуть обновленную версию своего продукта VMware vCloud Availability 1.0.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).

Сервис-провайдер, участвующий в программе vCloud Air Network (vCAN), предоставляет ресурсы своего облака как Disaster Recovery площадку на случай аварии в датацентре клиента.

Репликация данных виртуальных машин происходит с помощью виртуального модуля VMware vSphere Replication Appliance (VSRA), который развертывается только на стороне датацентра клиента. Технология vSphere Replication позволяет откидывать реплики виртуальных машин в удаленную инфраструктуру сервис-провайлера, при этом как только данные покидают хост VMware ESXi - они сразу же шифруются.

Таким образом, никто не получит доступ к вашим ВМ в удаленном датацентре:

Архитектура решения VMware vCloud Availability выглядит следующим образом:

Модуль vSphere Replication Appliance содержит в себе несколько компонентов, в частности vCloud Tunneling Agent (vCTA), который обеспечивает безопасное SSL-соединение с датацентром сервис-провайдера. На стороне же провайдера vCAN работают так называемые Cloud Proxy Cells, которые принимают данные и являются составляющей частью решения vCloud Director.

Также в составе vCD есть Hybrid DR API, через который происходит коммуникация с компонентом vSphere Replication Cloud Service (vRCS). vRCS предназначен для того, чтобы постоянно информировать vCloud Director о составе получаемой инфраструктуры клиента, конфигурациях виртуальных машин, а также их размещении в провайдерском датацентре. В этом случае VSRA делает все то же самое, что он и делал бы для инфраструктуры онпремизной репликации через vCenter.

Ну а на видео ниже можно узнать, как происходит развертывание решения VMware vCloud Air Disaster Recovery для инфраструктуры клиента, который настраивает соединение с инфраструктурой сервис-провайдера:

Вот тут детально рассказывается о предварительных требованиях для создания такой инфраструктуры аварийного восстановления:

Ну а здесь, собственно, мы можем посмотреть, как конфигурируется удаленный (резервный) сайт под восстановление инфраструктуры предприятия в случае аварии:

Таким вот образом настраивается репликация в VSRA:

А на последнем видео - показан тест восстановления инфраструктуры в облаке после сбоя в датацентре клиента:

Больше о продукте VMware vCloud Availability и решении vCloud Air Disaster Recovery можно узнать по этим ссылкам:

• VMware vCloud Availability
• VMware vCloud Director
• VMware vCloud Air Network

Не так давно мы писали о новой версии клиента для управления виртуальной инфраструктурой VMware vSphere Client 3.15 и забыли упомянуть, что тогда же вышла и обновленная версия клиента для управления отдельными хост-серверами - VMware ESXi Embedded Host Client 1.21. Напомним, что о прошлой версии Host Client 1.17 мы писали в марте этого года.

Посмотрим на новые возможности ESXi Embedded Host Client 1.21, которых не так уж и мало:

• Возможность увеличить размер датастора путем увеличения размера существующего экстента за счет использования доступного пространства на этом LUN.
• Был улучшен датастор браузер - теперь корректно обрабатываются операции копирования и перемещения при действиях с дисками VMDK.
• Корректная обработка горячего изменения сетевых адаптеров ВМ с MAC-адресами, назначенными сервером vCenter. Это предотвращает перегенерацию MAC-адресов при изменении портгрупп.
• При добавлении новых дисков их тип выставляется как "Thick", чтобы соответствовать поведению сервера vCenter в этом же рабочем процессе.
• Обработка отсутствующих данных о сертификатах в разделе Host -> Manage -> Security -> Certificates.
• В разделе изменения или добавления виртуального коммутатора vSwitch теперь есть данные о статусе и скорости соединения.
• Имя ВМ теперь отображается в самом начале в заголовке консоли и на вкладках.
• Улучшено изменение разрешения при вписывании консоли в текущее окно.
• В Firefox в неактивных полях ввода текст теперь более читаемый.
• Теперь демон hostd определяет имя файла создаваемых виртуальных дисков.
• Теперь нет ограничения по числу дисков, которые могут быть у виртуальной машины.
• Предотвращение замены регулярного выражения для неопределенного свойства OVA-модуля.
• Добавлена поддержка добавления пермиссий для групп.
• Исправлена ошибка для ситуации, когда диски ВМ размещались на некорректном датасторе.

Загрузить ESXi Embedded Host Client 1.21 в виде VIB-пакета можно по этой ссылке. Установить его очень просто - выполните следующую команду (VIB-файл должен лежать у вас по указанному пути):

esxcli software vib install -v /tmp/esxui.vib

Удаляется клиент вот таким образом:

esxcli software vib remove -n esx-ui

Список поддерживаемых браузеров на данный момент таков:

На днях компания VMware обновила свой главный клиент для управления виртуальной инфраструктурой до версии VMware vSphere Client 3.15 (напомним, что он построен на основе технологии HTML 5). Несмотря на то, что он еще много чего не умеет, в скором времени он заменит более медленный vSphere Web Client, работающий на базе старой технологии Adobe Air.

Последний раз мы писали о vSphere Client версии 3.13, поэтому приведем ниже основные возможности и улучшения последних двух версий клиента:

• Создание виртуальной машины с прицеплением к ней существующего виртуального диска vmdk.
• Создание ВМ с диском типа RDM.
• Совместимость с политиками хранилищ (Storage Policies), в том числе поддержка политики удаления ВМ.
• Ссылка "More info..." для VMware Tools на странице VM Summary.
• Действие "Customize Guest OS" для виртуальной машины. Для этого действия добавлены валидация и проверка пермиссий для мастеров Clone/Deploy VM.
• Нотификация для выполнения операций на одной или нескольких ВМ.
• Добавлена строчка "Managed By" в описании, что показывает, что хост находится под управлением vSphere Client.
• Создание ВМ с кастомной политикой управления питанием (Power Management, задается на странице Customize Hardware > VM Options).
• Улучшена производительность основного дэшборда.

Скачать VMware vSphere Client 3.15 можно по этой ссылке.

Многие пользователи виртуальной инфраструктуры VMware vSphere часто используют кастомизированные образы гипервизора VMware ESXi, который распространяется OEM-производителями оборудования, например, HP. Эти образы включают в себя специфические драйвера устройств, которые, зачастую, отсутствуют в стандартном комплекте поставки ESXi (это и понятно, так как нельзя поддерживать все устройства всех производителей в одном образе).

Между тем, многие администраторы обновляют такие образы достаточно редко - иногда по полгода ждут пока OEM-вендор выпустит очередную версию образа и накатывают его. Но ведь бывают критические обновления безопасности ESXi, которые нужно установить как можно скорее. Для этого нужно знать, как выглядит процедура обновления кастомного образа vSphere.

Во-первых, нужно понимать, что основные номера билдов и даты релиза гипервизора указаны в статье KB 2143832. А патчи в виде VIB-пакетов можно скачать с портала MyVMware здесь.

Во-вторых, есть утилита PowerCLI Image Builder (о ней мы писали вот тут), которая позволяет поддерживать актуальное состояние образа ESXi с точки зрения последних обновлений, но в то же время сохранять специфический контент кастомных образов.

Ну и, в-третьих, для тех, кто умеет пользоваться утилитой, есть простая команда, которая позволяет склонировать существующий профиль образа и обновить его пакеты, накатив последние патчи ESXi:

Set-ESXImageProfile $ClonedProfile -SoftwarePackage (Get-ESXSoftwarePackage -Newest)

Также у VMware есть скрипты PowerCLI, которые демонстрируют более тонкий подход к обновлению образов ESXi. Но надо отметить, что они официально не поддерживаются со стороны техподдержки VMware.

Итак, первый скрипт - esxi-image-creator.ps1 - представляет собой обертку к Image Builder и дает некоторые дополнительные возможности, которые часто требуются для кастомных образов ESXi. Например, он позволяет монтировать depot-файлы и включать или исключать VIB-пакеты из состава образов. Также там есть такие расширенные настройки, как указание билдов по датам выпуска, а не по номерам и т.п. Итоговый образ можно собрать в формате ISO или ZIP.

Второй скрипт - esxi-image-comparator.ps1 - показывает различия между двумя профилями образов ESXi. Эти различия можно показать в консоли или графическом интерфейсе, а также экспортировать в CSV-файл для последующего анализа.

Как видно из картинки, в процессе работы скрипта можно в интерактивном режиме включать или исключать профили для сравнения.

Вот пример использования утилиты при обновлении кастомного образа Cisco для ESXi 5.5 (обновление U3b от декабря 2015) с последними патчами VMware и обновленными драйверами Cisco для устройств enic и fnic. При этом исключается VIB-пакет tools-light для оптимизации использования с Auto Deploy:

esxi-image-creator.ps1 -NewProfileName Cisco_5.5_OEM_with_express_patch_11 -WriteZip -Files Vmware-ESXi-5.5.0-3248547-Custom-Cisco-5.5.3.2-Bundle.zip,ESXi550-201703001.zip,enic-2.3.0.13-offline_bundle-5367272.zip,fnic_driver_1.6.0.28_ESX55-offline_bundle-4179470.zip

Ну а вот так выглядит результат сравнения обновленного профиля с исходным:

Еще один пример - включение в образ Dell ESXi 6.0U3, который уже был обновлен Dell, патча patch 7a (5224934) с пакетами VIB для NSX и удаление VMware Tools для использования с Auto Deploy.

esxi-image-creator.ps1 -NewProfileName Dell_6.0_OEM_5224934_with_NSX -Files VMware-VMvisor-Installer-6.0.0.update03-5224934.x86_64-Dell_Customized-A01.zip,vxlan.zip,vShield-Endpoint-Mux-6.5.0esx60-4885300.zip -Acceptance PartnerSupported

Результат:

А вот пример генерации образа для HPE Proliant, содержащего последние обновления из репозитория HP, а также последние обновления оффлайн-бандла ESXi 6.5:

Add-EsxSoftwareDepot http://vibsdepot.hpe.com/index-ecli-650.xml

esxi-image-creator.ps1 -LeaveCurrentDepotsMounted -NewProfileName ESXi_6.5.0d_with_HPE_drivers -Files ESXi650-201704001.zip -Acceptance PartnerSupported

Надо отметить, что не следует использовать публичный репозиторий VMware image profile repository для создания кастомных образов, так как он содержит много различных версий и модификаций, что может привести к созданию образа, который невозможно будет использовать.

Но зато вот такая команда позволит сформировать таблицу с отличиями каждого из релизов VMware ESXi:

Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxi-image-comparator.ps1 | Export-Csv all_profiles.csv

Мораль поста такова - нужно пользоваться, по-возможности, кастомными образами ESXi от OEM-производителей, но не забывать накатывать обновления (особенно security patches) от обычных образов VMware ESXi, создаваемых VMware.

«ИТ-ГРАД» завершил обновление облачных площадок в Москве и Санкт-Петербурге и Казахстане, теперь облачные ЦОДы в DataSpace, SDN и AHOST.kz  работают под управлением vCloud Director 8.10.

vCloud Director– это средство управления облачной инфраструктурой VMware vSphere, предназначенное для сервис-провайдеров, предлагающих услуги по модели IaaS. Изменения, произошедшие в vCloud Director 8.10, также затронули конечных пользователей: в текущем релизе появилась ожидаемая и часто запрашиваемая функциональность, интересная для клиентов.

Основные возможности, которые теперь доступны из IaaS-облака«ИТ-ГРАД»:

• Virtual Machine Affinity Rules – теперь через консоль vCloud Director можно создавать правила раздельного/совместного существования виртуальных машин на хостах ESXi (affinity/anti-affinity rules). Это необходимо в случае, когда требуется указать, что отдельные группы ВМ должны совместно находиться на одном хосте либо, наоборот, размещаться раздельно на разных узлах. Последнее особенно актуально, если группа ВМ представляет собой некий кластер приложений.
• Storage Policy – появилась возможность гранулированного управления политиками хранилища в разрезе виртуальных дисков. Теперь Storage Policy задается для каждого диска виртуальной машины, а не для ВМ целиком, как это было в предыдущих версиях.
• Expanded Hardware Version – реализована поддержка обновленной версии виртуального железа Hardware Version 11.
• vCloud Director 8.10 теперь еще более тесно интегрирован с VMware NSX, а управление виртуальными сетями дата-центра происходит с помощью VMware NSX Manager. При этом шлюз VMware NSX Edge, разворачиваемый в организации, обладает преимуществами в отношении производительности, стабильности и высокой доступности.

«ИТ-ГРАД» на своих облачных площадках в ЦОД DataSpace и SDN использует платформу виртуализации сети VMware NSX 6.2.5.

Изменения, произошедшие в vCloud Director 8.10, в первую очередь направлены на повышение производительности приложений и рабочих нагрузок. Новая версия решения обеспечивает доступ к отдельным компонентам, которые активно используются приложениями, особенно чувствительными к производительности.

Узнать подробнее о новых функциях vCloud Director 8.10 можно из блога на VM Guru и на страницах первого блога о корпоративном IaaS.

В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.

Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.

Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:

• Настройка высокой доступности vSphere High Availability.
• Настройка балансировщика vSphere Distributed Resource Scheduler (DRS).
• Конфигурация vSphere Distributed Switch для трафика vSAN.
• Настройка vMotion для ВМ.
• Позволит убедиться в том, что все доступные накопители используются для кластера.
• Есть средства конфигурации хостового контроллера.
• Есть необходимая версия микрокода (firmware) хостового контроллера.

Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.

Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):

Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:

Конечно же, необходима настройка vSphere HA/DRS:

Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:

Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.

Как знают некоторые администраторы VMware vSphere, среди интерфейсов vSphere API есть механизм взаимодействия с виртуальными машинами через VMware Tools, который называется VMware vSphere Guest API.

Утилита VMware Tools Client, написанная Pierre Laine, позволяет подключиться к виртуальной машине через этот интерфейс, загружать/скачивать с нее файлы и скрипты и исполнять их. Это может оказаться полезным, когда вы потеряли сетевой доступ к виртуальной машине (например, внутри гостевой ОС что-то отвалилось).

VMware Tools Client соединяется с сервером vCenter, получает его иерархию через vCenter Inventory Service, после чего можно работать с виртуальными машинами для следующих целей:

• Выполнение в гостевой ОС отдельных команд (например, пинг из ВМ) или скриптов
• Загрузка, сохранение и удаление скриптов на ВМ (а также любых других файлов)
• Загрузка скрипта из файла

Утилита кроссплатформенная с интерфейсом на JavaFX, поэтому может быть запущена на Linux/Windows системах. Также она не требует установки. На данный момент она находится в бете версии 0.2. В составе идет база данных SQLLite, в которой хранятся логины/пароли от vCenter и виртуальных машин. Скачать VMware Tools Client можно по этой ссылке.

Последний день конференции VeeamON 2017, проходящей сейчас в Новом Орлеане, оказался не менее интересным и богатым на анонсы, чем предыдущие (вот они - День 0 / День 1 / День 2).

Вот основные анонсы последнего дня конференции:

Первый в списке - это новая технология Veeam Disaster Recovery in Microsoft Azure, предназначенная для восстановления инфраструктуры в облако Microsoft Azure и состоящая из двух основных компонентов - техника прямого восстановления из резервных копий и реплик непосредственно в облако Azure, а также утилита предоставления и восстановления сетевого доступа Veeam PN (она уже доступна как релиз-кандидат).

В рамках анонса этой возможности прежде всего было рассказано о новой утилите Veeam PN, которая представляет собой надстройку над OpenVPN, позволяющую создать инфраструктуру облачного восстановления не только данных, но и преобразования сетевых настроек для восстановления доступа к сетевым сервисам в случае восстановления инфраструктуры в резервном облаке Azure.

При этом большой плюс подхода Veeam DR in Microsoft Azure - это то, что компании не потребуется оплачивать и поддерживать инфраструктуру на стороне Azure - она развертывается и конфигурируется по запросу (для старта не нужна даже учетная запись Azure).

Следующий интересный анонс - это продукт Veeam Backup for Microsoft Office 365 версии 1.5, представляющий собой средство создания резервных копий из облака Microsoft на уровне приложения.

Также было рассказано о возможностях второй версии этого решения, которая также будет выпущена вскоре за 1.5. Теперь Veeam Backup сможет делать резервные копии SharePoint и данных хранилища OneDrive for Business.

Ну и заключительный анонс - это объявление о доступности для загрузки финальной версии продукта Veeam Management Pack (MP) for System Center v8 Update 4.

Его уже можно скачать с официального сайта Veeam, а вот его новые возможности:

1. Интеграция с Microsoft Operations Management Suite (OMS) и новые дэшборды.

Veeam MP теперь имеет интеграцию с OMS и предоставляет агрегированные данные мониторинга через Azure-based OMS консоль. Если у вас Microsoft System Center Operations Manager (SCOM) подключен к функционирующему сервису OMS с подпиской, то данные будут агрегироваться там с периодом 15 минут.

Veeam MP будет отображать состояния различных объектов инфраструктуры, таких как VMware vSphere, Microsoft Hyper-V и системы Veeam Backup & Replication. Процесс интеграции выглядит следующим образом:

1. Испорт файлов MBP из Veeam MP Resource Kit в SCOM.
2. Добавление представлений OMS из Veeam MP Resource Kit в консоль OMS.

Эти представления в OMS можно организовать каким угодно способом:

По умолчанию доступны следующие представления:

• Veeam Morning Coffee Dashboard for VMware vSphere
• Veeam Morning Coffee Dashboard for Microsoft Hyper-V
• Veeam Morning Coffee Dashboard for Backup
• Veeam Management Pack health dashboard

Например, Veeam Morning Coffee Dashboard дает информацию об общем состоянии систем резервного копирования и исполняемых задачах бэкапа:

2. Новые способы идентификации и решения проблем.

Несколько разнесенных систем SCOM можно объединить в едином представлении OMS и видеть общее состояние виртуальных датацентров под управлением Veeam MP. Также в едином пространстве OMS можно наблюдать за физическими и виртуальными инфраструктурами.

3. Алармы и отчеты.

Veeam MP, работая в паре с OMS, дает возможность просматривать OMS-алерты от серверов управления виртуальной инфраструктурой (vCenter или SCVMM). Высокоуровненые отчеты о состоянии инфраструктуры можно формировать для руководства.

4. Превью технологии Power BI для Veeam MP.

За счет использования коннектора OMS to Power BI можно отсылать данные Veeam MP в систему Power BI для дальнейшего анализа и визуализации. Например, с помощью следующего запроса можно сформировать датасет в Power BI:

"Type=Perf CounterName="cpuUsedPct" ObjectName="VMware vSphere Host" InstanceName<>_Total"

А дальше можно уже визуализовать его:

Скачать Veeam Management Pack (MP) for System Center v8 Update 4 можно по этой ссылке.

Недавно на сайте проекта VMware Labs появилась интересная утилита - Host Profiles CLI. Она позволяет администраторам VMware vSphere из командной строки выполнять те операции, которые недоступны в графическом интерфейсе механизма настройки хостов ESXi Host Profiles или доступны ограниченно (без средств автоматизации). Особо стоит отметить возможность совместного использования механизмов Auto Deploy и Host Profiles CLI.

Напомним, что профили хостов (Host Profiles) - это средство конфигурации серверов ESXi таким образом, что единый "золотой" профиль применялся к всем хостам, настраивая их единообразно, что уменьшает риски ошибок конфигурации, а также улучшает управляемость/обслуживание инфраструктуры и ее безопасность.

С помощью Host Profiles CLI из командной строки можно делать следующее:

• Кастомизация stateless-хостов Auto Deploy до их загрузки и присоединения к vCenter Server.
• Импорт/экспорт профилей хостов из локальных файлов.
• Привязка профиля к существующему кластеру.
• Установка единого рутового пароля в профиле или настройка профиля таким образом, чтобы использовать уникальные пароли root для каждого из хостов.
• Настройка системного кэша (stateless, cached или stateful install).
• Просмотр всех профилей хостов, доступных на vCenter Server.

Напомним, что начиная с vSphere 6.5, для механизма Host Profiles можно указывать параметры кастомизации отдельных хостов (IP-адреса, пароли и прочее) в CSV-файле. Но это можно делать только для хостов, которые были уже добавлены в Inventory сервера vCenter. С помощью Host Profiles CLI можно сделать прекастомизацию хостов через файлы CSV, которые будут развернуты через Auto Deploy (то есть, самих хостов пока еще нет в vCenter).

Ну и вот так можно делать импорт и экспорт профилей хостов (не пытайтесь делать импорт профиля для окружения с другим оборудованием хост-серверов):

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 export --file esxi65-nfs-gen8.vpf

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 import --file esxi65-nfs-gen8.vpf

А вот так можно установить пароль root для всех хостов один или свой для каждого:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type allhosts

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type perhost

Таким вот образом можно привязать профиль к кластеру:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 attach --entity dbcluster

Также посредством Host Profiles CLI можно установить тип развертывания хостов через Auto Deploy - Stateless caching (когда хост в случае массового сбоя и недоступности PXE-сервисов грузится из локальной кэшированной копии) или Stateful install (когда хост грузится с диска и уже больше не зависит от Auto Deploy). Вот как это делается:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 system-image host set \

--type stateful-install --firstdisk_arguments localesx,local --ignore_ssd --overwrite_vmfs

Более подробная информация об использовании Host Profiles CLI приведена в документации. Загрузить этот интерфейс можно по этой ссылке.

В начале мая компания VMware выпустила очередное обновление своего основного средства для управления инфраструктурой VMware vSphere - vSphere Client 3.13. Три недели назад мы писали о нововведениях версий 3.10 и 3.11, а сегодня расскажем о новых возможностях обновлений 3.12 и 3.13.

Давайте посмотрим, что нового в vSphere Client:

• Перекрывающие настройки распределения вычислительной нагрузки (VDRS) и нагрузки на хранилища (SDRS) могут быть теперь заданы.
• Для виртуальных машин появилась настройка кластеров непрерывной доступности Fault Tolerance.
• Стали доступны возможности Cross vCenter Server vMotion.
• В списке хостов можно выбрать столбец с версией ESXi (по умолчанию не выбран).
• Версия виртуального модуля видна в меню Help -> About VMware vSphere.
• Доступна настройка VM Compliance для механизма политик хранилищ (Storage Policies).
• Для распределенного коммутатора появились возможности добавления хостов и управления ими.
• Появилось действие Check Policy compliance для политик хранения машины (VM Storage Policy).
• Возможность создания новой виртуальной машины с кастомными VMware Tools и опциями загрузки (устанавливаются на странице Customize Hardware > VM Options).
• Улучшения для пользователей с ограниченными пермиссиями при конфигурации ВМ.

Загрузить VMware vSphere Client 3.13 можно по этой ссылке.

Некоторые из вас помнят, что в VMware vSphere 6.5 одной из новых возможностей гипервизора ESXi 6.5 стала функция его безопасной загрузки (Secure Boot). Об этом мы уже упоминали в посте с видеороликами о новых возможностях vSphere 6.5:

Суть механизма безопасной загрузки в vSphere 6.5 заключается в том, что загрузка подписанного кода гипервизора ESXi контролируется со стороны UEFI firmware, а также не разрешается исполнение неподписанных пакетов.

UEFI (Unified Extensible Firmware Interface) - это замена традиционному BIOS в серверах и настольных ПК. Механизм Secure Boot - это один из "протоколов" UEFI, который предоставляет возможности контроля загрузки подписанного кода за счет хранения цифровых сертификатов, которые хранятся в микрокоде (firmware) компьютера (signature database). Это все позволяет убедиться в том, что некий root kit не будет присутствовать в составе загружаемых компонентов и не предоставит доступ злоумышленнику на самом низком уровне.

Большинство UEFI содержит набор сертификатов по умолчанию типа x509 Microsoft UEFI Public CA, а также позволяет устанавливать собственные сертификаты дополнительно. Надо отметить, что эти сертификаты поставляются производителем серверов и обновляются вместе с его микрокодом.

Для обеспечения безопасной загрузки используются следующие компоненты:

• Загрузчик ESXi (boot loader) - он убеждается в том, что цифровая сигнатура кода не была изменена. Загрузчик подписан сертификатом Microsoft UEFI Public CA. Он также содержит VMware public key, с помощью которого проверяются компоненты VM Kernel, Secure Boot Verifier, а также пакеты VIB.
• Ядро VM Kernel - это также подписанная часть кода. Первое, что делает VM Kernel, это запускает Secure Boot Verifier.
• Secure Boot Verifier - он также хранит VMware public key и проверяет аутентичность всех VIB-пакетов, которые загружаются во время загрузки ESXi.
• VIB-пакеты (vSphere Installation Bundles) - эти пакеты, помимо реализуемых ими сервисов, содержат файл XML descriptor и файл цифровой подписи (digital signature file). Во время загрузки ESXi в памяти создается "карта" содержимого каждого из VIB-пакетов, соответственно не требуется проверять каждый из его файлов, а достаточно проверить подпись пакета целиком (это быстрее работает).

Вот как выглядит процесс загрузки хоста ESXi с точки зрения Secure Boot:

• Включение питания.
• UEFI Firmware валидирует загрузчик ESXi Boot Loader на предмет соответствия сертификату Microsoft внутри микрокода UEFI.
• ESXi Boot Loader валидирует компонент VM Kernel на предмет соответствия сертификату в Boot Loader.
• VM Kernel запускает компонент Secure Boot Verifier.
• Secure Boot Verifier валидирует каждый VIB-пакет на соответствие сертификату VMware, который находится в хранилище Secure Boot Verifier.
• Запускаются необходимые сервисы управления (DCUI, hostd и т.п.).

При апгрейде VMware ESXi прошлых версий с помощью ESXCLI происходит обновление сигнатур VIB-пакетов, но Boot Loader остается прежним, поэтому когда вы включите Secure Boot - возникнет ошибка. Как следствие - нужно будет переустановить ESXi.

Если вы обновляете ESXi из ISO-образа, то для некоторых старых VIB-пакетов сигнатуры могут не обновиться (например, кастомные драйвера, которые вы устанавливали отдельно), что приведет к неудаче при безопасной загрузке. То есть для нормального обновления из ISO нужно, чтобы все VIB-пакеты в этом образе обновили все предыдущие VIB. Надо отметить, что VIB-пакеты уровня Community supported не поддерживаются для безопасной загрузки (так как они не подписаны).

В составе VMware vSphere 6.5 есть специальный скрипт, который проверяет возможность безопасного апгрейда прошлой версии платформы.

Сначала надо проверить, что серверы поддерживают UEFI secure boot. Далее надо убедиться, что все ваши VIB-пакеты имеют хотя бы уровень Partner Supported, и у вас нет Community Supported пакетов.

Если вы обновили хост на ESXi 6.5, то можно выполнить следующий скрипт для проверки возможности включения Secure Boot:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Результатом будет строчка "Secure Boot can be enabled" или "Secure boot CANNOT be enabled".

Если вы включите Secure Boot в микрокоде сервера, но у вас есть неподписанные пакеты, то при загрузке сервера вы увидите розовый экран и сообщение о том, что нельзя проверить подписи VIB-пакетов:

Чтобы выйти из этой ситуации, надо выключить безопасную загрузку, удалить неподписанные VIB-пакеты и снова включить ее.

Еще одна фишка включенной функции Secure Boot - это то, что вы не сможете установить неподписанные VIB-пакеты с опцией force подобным образом:

"esxcli install software –d /drive/badvib.zip –force –<b>no</b>-sig-check"

Если говорить о модуле TPM, то он тут не участвует, и мало того - TPM 2.0 вообще не поддерживается со стороны VMware vSphere 6.5.

Ну и последнее. Если вы хотите использовать Secure Boot вместе с механизмом vSphere Auto Deploy, то вы должны добавить сертификат VMware в список UEFI firmware whitelist (DB). Это требуется потому, что только ESXi Boot Loader подписан сертификатом Microsoft, а часть кода PXE-загрузчика, которая грузится до Boot Loader, подписана сертификатом VMware. Более подробно об этом написано в KB 2148532.

Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:

Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.

Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):

А что для случая, если машины Witness VM разместить на разных площадках?

Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.

Поэтому нельзя перекрестно конфигурировать Witness VM для двух растянутых кластеров на двух площадках - нужно использовать третью площадку, чтобы кворум обеспечивался при любом виде сбоя на уровне одного из сайтов.

Многим из вас известен продукт для организации отказоустойчивых кластеров хранилищ под виртуальную инфраструктуруру StarWind Virtual SAN. Он выпускается уже в течение многих лет и давно зарекомендовал себя как лучшее в отрасли решение для создания программных хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Его основные возможности приведены тут и вот тут. А сегодня мы расскажем о том, что продуктом и всеми его функциями стало можно пользоваться фактически бесплатно!

Начиная с VMware vSphere 6.0, компания VMware предлагает администраторам очень удобный механизм для назначения прав доступа на самом высоком уровне при наличии нескольких серверов VMware vCenter - глобальные пермиссии (global permissions).

Для тех, кто использует режим vCenter Enhanced Linked Mode (ELM) с несколькими географически разделенными площадками и разнородными инфраструктурами, глобальные пермиссии - это отличное решение, так как они создаются один раз, после чего распространяются и (что самое главное) поддерживаются в согласованном состоянии на всех серверах vCenter связанной инфраструктуры в рамках одного домена Single Sign-On (SSO).

Вильям Лам, известный своими сценариями для автоматизации инфраструктуры vSphere, написал удобный скрипт GlobalPermissions.ps1, позволяющий добавлять и удалять глобальные пермиссии. Он содержит методы New-GlobalPermission и Remove-GlobalPermission, для которых можно задавать следующие параметры:

• vc_server - хост сервера vCenter
• vc_username - имя пользователя vCenter
• vc_password - пароль пользователя vCenter
• vc_user - пользователь vCenter, которому будут назначаться пермиссии
• vc_role_id - идентификатор Role ID, который связан с ролью vSphere на данном vCenter Server
• propagate - значение true или false для распространения пермиссий вниз по уровням иерархии

Чтобы получить параметр vc_role_id, нужно соединиться с vCenter Server и указать имя роли, выполнив сниппет ниже. В данном примере мы получаем ID административной роли с именем Admin:

(Get-VIRole -Name Admin).ExtensionData.RoleId

Вот пример создания новой глобальной пермиссии для одного из пользователей:

$vc_server = "192.168.1.51"

$vc_username = "administrator@vsphere.local"

$vc_password = "VMware1!"

$vc_role_id = "-1"

$vc_user = "VGHETTO\lamw"

$propagate = "true"

New-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user -vc_role_id $vc_role_id -propagate $propagate

А вот появление соответствующей пермиссии в интерфейсе vSphere Web Client как результат работы сценария выше:

Ну а вот так удаляется глобальная пермиссия:

Remove-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password -vc_user $vc_user

Посмотреть и загрузить сценарий GlobalPermissions.ps1 можно по этой ссылке.

В апреле компания VMware выпустила интересный документ, касающийся улучшений в плане производительности различных компонентов последней версии платформы виртуализации - "What's New in Performance? VMware vSphere 6.5".

В документе не только рассказывается об увеличении максимальных параметров конфигурации виртуальной среды и улучшениях различных аспектов производительности, но и большинство пунктов иллюстрируется графиками, по которым наглядно можно увидеть прогресс платформы.

Итак, посмотрим на количественные оценки улучшений. Вот так улучшилось число операций в минуту, которое может выдавать VMware vCenter 6.5:

А вот на столько уменьшилось время этих операций в VMware vSphere Web Client:

Кроме того, как вы знаете, в vSphere 6.5 есть HTML 5 Client (он сейчас называется просто vSphere Client). Основные операции он выполняет намного производительнее своего предшественника - Web Client:

Шифрование vMotion практически не влияет на время этой операции:

Но CPU при выполнении шифрования vMotion нагружается сильнее, соответственно требуется задействовать больше ядер процессора:

При шифровании дисков виртуальных машин производительность в IOPS также падает для обычных HDD-дисков, но это практически незаметно для SSD-дисков:

Ну и уменьшение Latency (задержки) при использовании технологии Direct Path I/O для сетевого адаптера, очень близко к нативной производительности:

Скачать документ "What's New in Performance? VMware vSphere 6.5" можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезность для виртуальной инфраструктуры VMware vSphere - ESXi Learnswitch. Эта штука представляет собой реализацию механизмов MAC Learning и Filtering, работающая как обертка для виртуального коммутатора ESXi (при этом обязательно требуется Distributed Virtual Switch).

ESXi Learnswitch поддерживает несколько MAC-адресов виртуальных сетевых адаптеров (vNIC) и фильтрацию пакетов, исходящих из некорректных портов, на основе алгоритма поиска MAC-адреса получателя. Это позволяет повысить производительность работы сети для вложенных гипервизоров ESXi (которые генерируют множество MAC-адресов ВМ) и использования технологии контейнеров на базе виртуальных машин.

Вот какие возможности предоставляет ESXi Learnswitch:

• Техники learning и filtering на основе оверлейных сетей (Overlay Network).
• Техника обнаружения MAC Address learning на основе VLAN ID или VXLAN ID на аплинке и оконечных портах (leaf port).
• Фильтрация пакета на аплинке/оконечном порту, если MAC-адрес обнаружился на другом порту.
• Выводимая таблица адресов размером 32к на одну систему.
• Поддержка устаревания MAC-адреса (MAC Address aging) с дефолтным временем жизни 5 минут (настраивается).
• Сбрасывание неизвестных юникастовых пакетов.
• Отдельный модуль доступный как VIB-пакет для установки.
• Интерфейс командной строки net-learnswitch CLI для отображения таблицы MAC-адресов, конфигураций и статистики.

Загрузить ESXi Learnswitch можно по этой ссылке. Отличная статья о данном средстве располагается вот тут.

Вслед за снятием с продаж продукта VMware vSphere Data Protection, компания VMware напомнила нам о том, что вскоре прекратится выпуск продукта VMware vSphere Management Assistant (vMA), который пока еще доступен для скачивания (версия 6.5, которая вышла вместе с vSphere 6.5). Об этом было объявлено еще в мае прошлого года при выпуске обновления vSphere 6.0:

Напомним, что этот продукт позволяет централизованно управлять хост-серверами VMware ESXi за счет автоматизации операций системных администраторов. По-сути, vSphere Management Assistant представляет собой "вынесенную" за пределы серверов ESXi сервисную консоль (консольную ОС), которая для виртуальной инфраструктуры присутствует в единственном экземпляре, но централизованно исполняет сценарии на хостах, используя различные интерфейсы VMware vSphere.

Теперь вместо vMA предлагается использовать интерфейсы vCLI и PowerCLI. В целом, этот подход выглядит достаточно логичным - большинство функций удаленного управления платформой взяли на себя эти фреймворки, а сами ESXi и vCenter отлично управляются через стандартные средства и API.

Сама VMware предлагает использовать интерфейс vSphere Command Line Interface (vCLI) в качестве альтернативы vMA. Между тем, она заявляет о том, что команды esxcfg- и vicfg- также будут выведены из эксплуатации (deprecated). Поэтому администраторам vSphere стоит проверить, не используются ли эти две команды в старых скриптах для управления виртуальной инфраструктурой (подробнее о заменах для этих команд - тут).

Вот какие еще предлагаются альтернативы интерфейсу vCLI и устаревшему модулю vMA:

• Фреймворк PowerCLI и средство кроссплатформенного использования PowerCLI Core.
• Docker Container с VMware Tools внутри и интегрированными в него нужными административными интерфейсами. Эта штука называется vmware-utils и содержит в себе множество зашитых интерфейсов, а именно:
  • vSphere CLI 6.5
  • PowerCLI Core 1.0
  • vSphere Management SDK 6.5
  • vSphere SDK for Perl 6.5
  • vSphere SDK for Ruby (rbvmomi)
  • vSphere SDK for Python (pyvmomi)
  • vSphere Automation SDK for Ruby 6.5
  • vSphere Automation SDK for Python 6.5
  • vSphere Automation SDK for Perl 6.5
  • vSphere Automation SDK for Java 6.5
  • VSAN Management SDK for Ruby 6.5
  • VSAN Management SDK for Python 6.5
  • VSAN Management SDK for Java 6.5
  • VSAN Management SDK for Perl 6.5
  • Virtual Disk Development Kit (VDDK) 6.5
  • OVFTool 4.2
  • PowerCLI Community Repository
  • PowerCLI Core Docker Container Samples
  • William Lam's vGhetto Script Repository
  • Pyvmomi Community Samples
  • Docker Client v1.12.3
  • Docker Compose v1.8.1

Подробнее о vmware-utils можно почитать вот тут.

Ну а пока VMware vSphere Management Assistant все еще доступен для скачивания по этой ссылке.

Возможно не все из вас в курсе, что у VMware есть удобное средство для скачивания продуктов линейки VMware vSphere и других решений для создания виртуального датацентра - VMware Software Manager. Эта штука позволяет после аутентификации через MyVMware скачивать VMware vSphere, vCenter Converter, vRealize Automation и другие продукты компании:

Зайдя в раздел каждого из продуктов, вы увидите его текущую и прошлые версии:

А открыв пункт VMware vSphere, можно увидеть все компоненты инфраструктуры виртуализации, доступные для скачивания:

VMware Software Manager - Download Service может даже скачивать сам себя!

Также данное средство может автоматически определять наличие новых версий продуктов VMware. Кроме того, оно умеет определять был ли загружен файл целиком, без повреждений.

Форум по продукту находится здесь, а скачать VMware Software Manager - Download Service можно по этой ссылке.

Как знают все администраторы vSphere, в инфраструктуре виртуализации есть основной пароль компонента Single Sign-On (SSO), являющегося частью служб Platform Service Controller (PSC). SSO отвечает за предоставление токена авторизации пользователю, который соединяется с vCenter и использует остальные решения, которые с ним интегрированы.

Если вы забыли пароль SSO, то никак не сможете администрировать основные службы PSC и vCenter. Также вы не сможете никаким способом повысить одного из пользователей с любой ролью до администратора SSO.

Но есть способ восстановить/сбросить пароль Single Sign-On, если вы используете vCenter Server Appliance (vCSA). Для этого нужно зайти на vCSA под пользователем root (его же вы не забыли, правда?):

После чего ввести команду для доступа к шеллу:

shell.set --enabled true

После этого напишите shell и нажмите Enter:

Далее запустите VDC админ-тул, и вы увидите вот такой результат:

Нажмите клавишу <3>, после чего у вас попросят ввести аккаунт (Account UPN), для которого будет сгенерирован временный пароль. Введите administrator@vsphere.local:

После этого с данным паролем войдите в vCenter Single Sign-On:

Ну а там уже перейдите в Administration>Single Sign On > Users и выберите Edit для пользователя Administrator. Там можно сменить пароль:

Это, кстати, говорит о том, что пароль root для vCenter Server Appliance нужно хранить особенно внимательно и не забывать.

Недавно мы писали об анонсированных новых возможностях продукта для организации кластеров хранилищ VMware vSAN 6.6, а вчера он стал официально доступен для скачивания. Так как VMware vSAN работает в рамках инфраструктуры серверной виртуализации VMware vSphere, были также выпущены обновления ESXi 6.5d и vCenter 6.5d, поддерживающие vSAN 6.6.

Обратите внимание, что VMware Horizon 7.1 уже поддерживает VMware vSAN 6.6.

Напомним также, что совсем недавно выходил апдейт VMware vCenter 6.5c, в котором была исправлена уязвимость компонента Apache BlazeDS. Что касается обновления ESXi 6.5d, то оно включает в себя поддержку vSAN 6.6, исправления некоторых ошибок а также отображения статусов VMware vSAN health checks в интерфейсе клиента ESXi Host Client (он же Embedded Host Client).

Загрузить VMware vSAN 6.6 в составе платформы VMware vSphere 6.5 и ее компонентов можно по этой ссылке.

Ну и одновременно с этими релизами была выпущена также обновленная версия платформы VMware vSphere Integrated Containers 1.1.

Давайте посмотрим на новые возможности VIC 1.1:

• Унифицированный OVA-установщик для всех трех компонентов решения.
• Возможность апгрейда с версии 1.0.
• Официальная поддержка vSphere Integrated Containers Management Portal.
• Унифицированный пользовательский интерфейс для vSphere Integrated Containers Registry и vSphere Integrated Containers Management Portal.
• Отдельный плагин для HTML5 vSphere Client (он же vSphere Client теперь).
• Поддержка Docker Client 1.13 и Docker API версии 1.25.
• Поддержка использования компонента Notary совместно с vSphere Integrated Containers Registry.
• Поддержка дополнительных команд Docker, которые можно найти в документации.

Загрузить VMware vSphere Integrated Containers 1.1 можно по этой ссылке.

На прошлой неделе мы писали о том, что компания VMware выпустила релиз-кандидат своего основного документа по обеспечению безопасности виртуальной инфраструктуры. Ну а на днях вышла окончательная версия VMware vSphere 6.5 Security Configuration Guide (ранее он назывался Hardening Guide).

В прошлом посте мы рассказывали о том, что 65% настроек, приведенных в документе, либо задаются администратором, либо уже сделаны VMware по умолчанию, и администратору лишь нужно регулярно проверять, что ничего не изменилось. Поэтому здесь мы подробнее остановимся на том, что было удалено из документа и добавлено в него, чтобы понимать, как у VMware построен процесс работы с аудитом основного руководства по безопасности.

Удаленные настройки

С каждым релизом vSphere команда инженеров VMware проводит аудит каждой настройки и сверяет ее актуальность в отношении текущего функционала vSphere. Например, были удалены рекомендации относительно настройки VM.disable-VMTools-autoinstall, которая подразумевала, что можно примонтировать некорректную исошку с тулзами, автоинстал которой поселит вредоносное ПО в вашу госетвую ОС. Но в vSphere 6.5 монтируются только подписанные исошки с VMware Tools, а значит эта опасность ушла. Ну и к тому же, дефолтная политика обновления ESXi подразумевает ручное обновление тулзов, а значит указанная настройка не вполне актуальна.

Второй пример - это настройка vCenter.verify-nfc-ssl, которая была удалена, поскольку VMware больше не поддерживает "толстый" C#-клиент. Ранее этот клиент не использовал SSL для транзакций копирования файлов (Network File Copy), хотя отдельной настройкой шифрование можно было включить. Сейчас это стало неактуально.

Ну а вот полный список удаленных настроек:

• VM.disable-VMtools-autoinstall
• VM.disable-unexposed-features-biosbbs
• VM.disable-unexposed-features-getcreds
• VM.disable-unexposed-features-toporequest
• VM.disable-unexposed-features-trashfolderstate
• VM.disable-vix-messages
• VM.prevent-device-interaction-connect
• VM.prevent-device-interaction-edit
• vCenter.verify-nfc-ssl

Каждая из этих настроек была удалена по той причине, что либо она потеряла актуальность из-за того, что фичи больше нет, либо изменился рабочий процесс, касающийся этой настройки, либо изменилось дефолтное состояние настройки.

Добавленные настройки

Во-первых, в документ были добавлены новые колонки. Это DISA STIG ID (ссылка на соответствующие гайдлайны правительства США), а также "Hardening" и "Site Specific Setting". Колонка Hardening указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации, а Site Specific Setting говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.

Также была добавлена колонка "Audit Setting", которая говорит о том, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. В то же время, они могут быть изменены осознанно в соответствии с корпоративными политиками, и в этом нет ничего плохого (например, настройка *timeout).

Например, настройка, которая была добавлена - это ESXi.Audit-SSH-Disable. По умолчанию доступ по SSH отключен для хостов ESXi, но иногда администраторы могут включать его для решения своих задач. Поэтому эта настройка и помечена как "Audit Setting".

Также появились настройки VM.Enable-VGA-Only-Mode и VM.disable-non-essential-3d-features. Первая отключает функциональность SVGA для виртуальной машины. Эта настройка помечена как Site Specific, то есть администратор с параноидальным уровнем отношения к безопасности может отключить SVGA-драйвер для консольных гостевых ОС, но эта настройка, конечно же, не помечена как Hardening, чтобы все повально не стали отключать SVGA-драйверы, а потом писали письма в поддержку с вопросом о том, чего это не работает гостевая ОС.

Настройка disable 3D по умолчанию отключена, но помечена как "Audit Setting", чтобы время от времени просматривать, не включил ли ее зачем-то администратор.

Отметим, что никаких значительных изменений с момента релиз-кандидата документа не произошло. Скачать финальную версию VMware vSphere 6.5 Security Configuration Guide можно по этой ссылке (там же находятся и остальные руководства по безопасности от VMware).

На днях компания VMware выпустила версию 3.11 своего клиента для управления виртуальной инфраструктурой на базе технологии HTML 5 - vSphere Client. Совсем скоро он заменит собой старый клиент vSphere Web Client, в котором пока еще шире функциональность, но vSphere Client уже стремительно наверстывает разрыв.

Давайте посмотрим, что нового появилось в VMware vSphere Client версий 3.10 и 3.11:

• Консолидация снапшотов виртуальных машин.
• Перемещение ВМ в пределах хостов и кластеров.
• Перемещение ВМ из датастора в кластер датасторов драг энд дропом.
• Расширенные графики производительности теперь могут отображаться как составные графики (несколько составляющих одного параметра - как на картинке выше).
• Появился контент в разделе VM Storage Policy.
• Добавились операции import, export, duplicate и delete для спецификации настройки ВМ (customization specification).
• Появились параметры Host CPU и Host Memory в списке ВМ.
• Возможность клонирования ВМ или шаблонов между серверами vCenter на датастор кластера хранилищ.
• Добавление существующего VMDK-диска как нового для новой виртуальной машины.
• Действие для смены политики хранилищ по умолчанию.
• Графики производительности можно экспортировать в картинки или файлы CSV.

Скачать VMware vSphere Client 3.11 можно по этой ссылке.

Все администраторы платформы VMware vSphere знают, что такое параметры Shares и Reservation, но не все понимают, как именно они работают для виртуальных машин и пулов ресурсов. Мы уже затрагивали эту тему для виртуальных машин, не погружаясь в распределение ресурсов между пулами (хотя там все работает точно так же).

Основным источником знаний о Reservation и Shares является документ "Resource Management Guide", однако он большой и нудный, а на днях VMware выпустила более простую версию, сфокусированную на управлении кластером DRS с точки зрения резерваций и шар - "DRS Cluster Management with Reservation and Shares".

Именно из этого документа лучше узнать, как работают Shares (распределение ресурсов) и Reservations (гарантирование ресурсов) в рамках отдельных виртуальных машин, пулов ресурсов в рамках кластера DRS с учетом возможности заимствования ресурсов из родительского пула (expandable reservation).

Конечно же, если вы администратор платформы VMware vSphere, то вы должны были разобраться с этим всем еще в самом начале, но если какие-то аспекты работы механизмов гарантирования и распределения ресурсов вам остались непонятными, обязательно пробегитесь по документу "DRS Cluster Management with Reservation and Shares".

Компания VMware на днях выпустила Release Candidate версию своего основного руководства по обеспечению безопасности виртуальной среды серверной виртуализации - vSphere 6.5 Security Configuration Guide (ранее он назывался Hardening Guide).

Традиционно Hardening Guide представляет собой Excel-табличку с необходимыми конфигурациями серверов ESXi, виртуальных машин, сетей и т.п. для обеспечения безопасной работы виртуальной инфраструктуры на различных уровнях (от легкой до параноидальной защиты):

Интересная картинка, которую приводит VMware в отношении состояния конфигурационных настроек по умолчанию при развертывании среды vSphere:

Здесь раздел "Non-Hardening" означает, что рекомендуемые с точки зрения безопасности настройки либо уже выставлены по умолчанию, либо задаются пользователем (например, IP-адрес сервера NTP). Оставшиеся 35% настроек как раз могут быть изменены администратором vSphere, чтобы сделать инфраструктуру более защищенной.

Однако помните, что повышение уровня безопасности неизбежно рождает повышение уровня геморроя в связи с бОльшими неудобствами пользователей и администраторов, которые должны делать больше дополнительных действий и ждать дольше завершения рабочих процессов. Очевидно, что безопасность - это палка о двух концах.

Пока в документе всего 68 настроек, но не исключено, что их количество будет увеличено. Соответственно, как Hardening предполагается всего 24 настройки.

18 из этих настроек - это настройки раздела VM.disable-unexposed-features.*, которые касаются скрытых/недокументированных возможностей ВМ, а остальные 6 настроек касаются следующего:

• 3 штуки - это настройки стандартного vSwitch из значений accept в reject (эти рекомендации есть еще со времен самого первого Hardening Guide).
• 1 настройка - это BPDU filter.
• 1 штука - это просто рекомендация своевременно патчить хосты ("Apply your ESXi patches").
• 1 настройка - это "Disable TLS 1.0/1.1", то есть отключение старых версий протокола TLS, у которых есть проблемы с безопасностью (более подробно смотрите тут).

TLS 1.0/1.1 не отключен по умолчанию, так как некоторые системы продолжают использовать его, соответственно отключение может привести к различным проблемам, поэтому делать это нужно осознанно.

Из руководства были удалены рекомендации, касающиеся следующих настроек (сделано это было после консультаций с инженерами vSphere):

VM.disable-VMtools-autoinstall

 VM.disable-unexposed-features-biosbbs

 VM.disable-unexposed-features-getcreds

 VM.disable-unexposed-features-toporequest

 VM.disable-unexposed-features-trashfolderstate

 VM.disable-vix-messages

 VM.prevent-device-interaction-connect

 VM.prevent-device-interaction-edit

vCenter.verify-nfc-ssl

Скачать документ VMware vSphere 6.5 Security Configuration Guide и оставить фидбэк по нему можно по этой ссылке. Финальная версия ожидается 13 апреля.

На днях компания VMware анонсировала конец жизненного цикла (End of Availability) с 5 апреля для продукта vSphere Data Protection (VDP), предназначенного для резервного копирования и репликации виртуальных машин на платформе ESXi.

Платформа VMware vSphere 6.5 станет последней, которая включает в себя данное средство - для всех последующих версий решения резервное копирование виртуальных машин нужно будет осуществлять с помощью сторонних продуктов. Например, Veeam Backup and Replication - он уже и так является практически стандартом на рынке резервного копирования виртуальных машин и занимает большую его часть, так что ничего страшного для большинства не произойдет.

На тему окончания поддержки Data Protection есть специальная статья KB 2149614, в которой говорится, что теперь VMware будет фокусироваться на интерфейсе vSphere Storage API, отдавая нишу продуктов для резервного копирования партнерам. В то же время VMware продолжит предоставление поддержки по VDP текущим пользователям в соответствии с правилами, указанными в VMware Lifecycle Product Matrix, до даты End of General Support (EOGS).

Тем, кто уже использует Data Protection компания Dell дарит бесплатную лицензию на 3 года на продукт Avamar Virtual Edition (AVE) для первых 4 ТБ защищаемых данных. Когда так просто раздают лицензии - становится понятно, что продукт не вполне конкурентоспособен. Поэтому берите лучше Veeam)

Ну и для особо обеспокоенных снятием с производства продукта vSphere Data Protection компания VMware выпустила специальный FAQ.

Не все знают, что в VMware vSphere Web Client есть удобное средство для просмотра основных логов VMware vSphere на хостах с поиском по ним, которе можно использовать для анализа и разрешения возникающих в виртуальной инфраструктуре проблем.

Чтобы его запустить, в VMware vSphere 5.5 надо выбрать пункт Log Browser в навигаторе:

Однако в VMware vSphere 6.0 и 6.5 этот плагин был отключен, в связи с чем его нет в данном меню. Но достаточно его включить, чтобы можно было использовать это удобное средство анализа лог-файлов.

Чтобы сделать это на VMware vCenter Server Appliance (vCSA) нужно:

• Зайдите в оболочку vCenter Server Appliance Bash Shell под администратором.
• Перейдите к файлу манифеста, который по умолчанию расположен вот в этой директории: /usr/lib/vmware-vsphere-client/plugin-packages/logbrwoser.
• Переименуйте файл plugin-package.xml.unused в plugin-package.xml и сохраните его у себя.
• Из vSphere Web Client перезапустите службу VMware Service Lifecycle Manager API.

На VMware vCenter для Windows процедура выглядит следующим образом:

• Перейдите к файлу манифеста, который по умолчанию расположен вот в этой директории: C:\ProgramData\VMware\vCenterServer\runtime\vsphere-client\plugin-packages\logbrowser.
• Переименуйте файл plugin-package.xml.unused в plugin-package.xml и сохраните его у себя.
• Из vSphere Web Client перезапустите службу VMware Service Lifecycle Manager API.

После этого пункт Log Browser появится на вкладке Monitor клиента vSphere Web Client.